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1. Status of this Memo 


This memo defines a network management architecture that uses the 
International Organization for Standardization's (ISO) Common 
Management Information Services/Common Management Information 
Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture 
provides a means by which control and monitoring information can be 
exchanged between a manager and a remote network element. In 
particular, this memo defines the means for implementing the Draft 
International Standard (DIS) version of CMIS/CMIP on top of Internet 
transport protocols for the purpose of carrying management 
information defined in the Internet-standard management information 
base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks 
while CMIS/CMIP moves toward becoming an International Standard. 
Together with the relevant ISO standards and the companion RFCs that 
describe the initial structure of management information and 
management information base, these documents provide the basis for a 
comprehensive architecture and system for managing TCP/IP-based 
internets, and in particular the Internet. 


The Internet Activities Board (IAB) has designated two different 
network management protocols with the same status of "Draft Standard" 
and "Recommended". 


The two protocols are the Common Management Information Services and 
Protocol over TCP/IP (CMOT) (this memo) and the Simple Network 
Management Protocol (SNMP) [4]. 
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The IAB intends each of these two protocols to receive the attention 
Of implementers and experimenters. The IAB seeks reports of 
experience with these two protocols from system builders and users. 


By this action, the IAB recommends that all IP and TCP 
implementations be network manageable (e.g., implement the Internet 
MIB [3], and that implementations that are network manageable are 
expected to adopt and implement at least one of these two Internet 
Draft Standards. 


Distribution of this memo is unlimited. 
2. Introduction 


As reported in RFC 1052, "IAB Recommendations for the Development of 
Internet Network Management Standards" [1], the Internet Activities 
Board (IAB) has directed the Internet Engineering Task Force (IETF) 
to coordinate the work of three working groups in the area of network 
management. First, the MIB working group was charged with the 
specification and definition of elements to be included in the 
Management Information Base (MIB). Second, the SNMP working group 
was charged with defining the modifications to the Simple Network 
Management Protocol (SNMP) necessary to accommodate the short-term 
needs of the network vendor and operations communities. Third, the 
Netman working group was directed to meet the longer-term needs of 
the Internet community by developing a network management system 
based on ISO CMIS/CMIP. Both the Netman working group and the SNMP 
working group were directed to align their work with the output of 
the MIB working group in order to ensure compatibility of management 
information between the short-term and long-term approaches to the 
management of TCP/IP-based internets. This will enable a smooth 
transition from the short-term protocol (SNMP) to the long-term 
protocol (CMIP). 


The MIB working group has produced two memos. RFC 1065 [2] defines 
the Structure of Management Information (SMI) that is necessary for 
naming and defining managed objects in the MIB. RFC 1066 [3] defines 
the list of managed objects contained in the initial TCP/IP MIB. The 
SNMP working group has produced a memo [4] giving the protocol 
specification for SNMP and providing the SNMP protocol-specific 
interpretation of the Internet-standard MIB defined in RFC 1066. 


This memo is the output of the Netman working group. As directed by 
the IAB in RFC 1052, it addresses the need for a long-term network 


management system based on ISO CMIS/CMIP. The network management 
approach of using ISO protocols in a TCP/IP environment to manage 
TCP/IP networks can be described as "CMIP Over TCP/IP" (CMOT). This 


memo specifies the CMOT architecture and the protocol agreements 
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necessary to implement CMIP and accompanying ISO protocols over the 
TCP and UDP transport protocols. In addition, this memo provides an 
interpretation of RFC 1066 that makes it possible to use CMIP to 
convey management information defined in the Internet-standard MIB. 


There is widespread vendor support for the CMOT approach to network 


management. This is amply shown by the Netman demonstration of 
prototype CMOT implementations at the Interop '88 TCP/IP 
Interoperability Conference. The demonstration also showed the 


feasibility and power of the CMIS/CMIP framework for multivendor 
network management. Now that CMIS/CMIP has been voted a Draft 
International Standard (DIS), many vendors feel that the ISO standard 
has become a stable basis for product development. The clear need to 
standardize this development has led to the present profile of CMIP. 
It is expected that this profile will not change while the ISO 
standard moves from DIS status to International Standard (IS) status. 
If, however, the standard does change unexpectedly, the Netman 
working group will review such changes for appropriate action. 


Another rationale for the CMOT approach is that it will facilitate 
the early use of ISO network management standards in large 
operational networks. This will make it possible for the Internet 
community to make valuable recommendations to ISO in the language of 
OSI management based on actual experience with the use and 
implementation of these standards. There is continuing network 
management standards development work in ISO where such contributions 
would be valuable. 


The CMOT architecture is based on the Open Systems Interconnection 
(OSI) management framework and models developed by ISO. This memo 
contains a set of protocol agreements for implementing a network 
management system based on this architecture. The protocol agreement 
sections of this memo must be read in conjunction with ISO and 
Internet documents defining specific protocol standards. Documents 
defining the following ISO standards are required for the 
implementor: Abstract Syntax Notation One (ASN.1) [5, 6], Association 
Control (ACSE) [7, 8], Remote Operations (ROSE) [9, 10], Common 
Management Information Services (CMIS) [11], and Common Management 
Information Protocol (CMIP) [12]. RFC 1085 [13] is required for the 
specification of a lightweight presentation layer protocol used in 
this profile. In addition, RFC 1065 [2] and RFC 1066 [3] are 
required for a definition of the initial SMI and MIB to be used with 
the CMOT management system. 


This memo is divided into two main parts. The first part presents 
concepts and models; the second part contains the protocol agreements 
necessary for implementation of the CMOT network management system. 
The first part of the memo is divided into three sections: section 3 
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contains tutorial information on the OSI management framework; 
section 4 defines the basic CMOT approach; and section 5 discusses 
the area of management information and specifies how the abstract 
management information defined in the Internet-standard SMI and MIB 
map into CMIP. The second part of this memo is divided into sections 
for each of the protocols for which implementors’ agreements are 
needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol. 
The protocol profile defined in this part draws on the technical work 
of the OSI Network Management Forum [14] and the Network Management 
Special Interest Group (NMSIG) of the National Institute of Standards 
and Technology (NIST) (formerly the National Bureau of Standards). 
Wherever possible, an attempt has been made to remain consistent with 
the protocol agreements reached by these groups. 
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Part I: Concepts and Models 
3. The OSI Management Framework 


The OSI management framework [15] presents the basic concepts and 
models reguired for developing network management standards. OSI 
management provides the ability to monitor and control network 
resources, which are represented as "managed objects." The following 
elements are essential for the description of a network management 
architecture and the standardization of a network management system: 
a model or set of models for understanding management; a common 
structure of management information for registering, identifying, and 
defining managed objects; detailed specifications of the managed 
objects; and a set of services and related protocols for performing 
remote management operations. 


3.1. Architectural Overview 


The basic concepts underlying OSI network management are quite simple 
[16]. There reside application processes Called "managers" on 
managing systems (or management stations). There reside application 
processes Called "agents" on managed systems (or network elements 
being managed). Network management occurs when managers and agents 
conspire (via protocols and a shared conceptual schema) to exchange 
monitoring and control information useful to the management of a 
network and its components. The terms "manager" and "agent" are also 
used in a loose and popular sense to refer to the managing and 
managed system, respectively. 


The shared conceptual schema mentioned above is a priori knowledge 
about "managed objects" concerning which information is exchanged. 
Managed objects are system and networking resources (e.g., a modem, a 
protocol entity, an IP routing table, a TCP connection) that are 
subject to management. Management activities are effected through the 
manipulation of managed objects in the managed systems. Using the 
management services and protocol, the manager can direct the agent to 
perform an operation on a managed object for which it is responsible. 
Such operations might be to return certain values associated with a 
managed object (read a variable), to change certain values associated 
with a managed object (set a variable), or perform an action (such as 
self-test) on the managed object. In addition, the agent may also 
forward notifications generated asynchronously by managed objects to 
the manager (events or traps). 


The terms "manager" and "agent" are used to denote the asymmetric 
relationship between management application processes in which the 
manager plays the superior role and the agent plays the subordinate. 
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However, the specification of the management protocol (CMIP) defines 
a peer protocol relationship that makes no assumptions concerning 
which end opens or closes a connection, or the direction of 
management data transfer. The protocol mechanisms provided are fully 
symmetric between the manager and the agent; CMIS operations can 
originate at either the manager or agent, as far as the protocol is 
concerned. This allows the possibility of symmetric as well as 
asymmetric relationships between management processes. Most devices 
will contain management applications that can only assume the agent 
role. Applications on managing systems, however, may well be able to 


play both roles at the same time. This makes possible "manager to 
manager" communication and the ability of one manager to manage 
another. 


3.2. Management Models 


Network management may be modeled in different ways. Three models 
are typically used to describe OSI management [17, 18]. An 
organizational model describes ways in which management can be 
administratively distributed. The functional model describes the 
management functions and their relationships. The information model 
provides guidelines for describing managed objects and their 
associated management information. 


3.2.1. The Organizational Model 


The organizational model introduces the concept of a management 
"domain." A domain is an administrative partition of a network or 
internet for the purpose of network management. Domains may be 
useful for reasons of scale, security, or administrative autonomy. 
Each domain may have one or more managers monitoring and controlling 
agents in that domain. In addition, both managers and agents may 
belong to more than one management domain. Domains allow the 
construction of both strict hierarchical and fully cooperative and 
distributed network management systems. 


3.2.2. The Functional Model 


The OSI Management Framework [15] defines five facilities or 
functional areas to meet specific management needs. This has proved 
to be a helpful way of partitioning the network management problem 
from an application point of view. These facilities have come to be 
known as the Specific Management Functional Areas (SMFAs): fault 
management, configuration management, performance management, 
accounting management, and security management. Fault management 
provides the ability to detect, isolate, and correct network 
problems. Configuration management enables network managers to 
change the configuration of remote network elements. Performance 
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management provides the facilities to monitor and evaluate the 
performance of the network. Accounting management makes it possible 
to charge users for network resources used and to limit the use of 
those resources. Finally, security management is concerned with 
managing access control, authentication, encryption, key management, 
and so on. 


3.2.3. The Information Model 


The OSI Management Framework considers all information relevant to 
network management to reside in a Management Information Base (MIB), 
which is a "conceptual repository of management information." 
Information within a system that can be referenced by the management 
protocol (CMIP) is considered to be part of the MIB. Conventions for 
describing and uniguely identifying the MIB information allow 
specific MIB information to be referenced and operated on by the 
management protocol. These conventions are called the Structure of 
Management Information (SMI). The information model is described 
more fully in section 5. 


3.3. ISO Application Protocols 


The following ISO application services and protocols are necessary 
for doing network management using the OSI framework: ACSE, ROSE, and 
CMIS/CMIP. All three of these protocols are defined using ASN.1 [5]. 
The ASN.1 modules defining each of these protocols are found in the 
relevant standards documents. The encoding rules for ASN.1 [6] 
provide a machine-independent network representation for data. 


A brief overview of the terminology associated with the OSI 
application layer structure is presented here. A complete treatment 
of the subject can be found in the OSI Application Layer Structure 
document [22]. 


In the OSI environment, communication between "application processes" 
is modeled by communication between application entities. An 
"application entity" represents the communication functions of an 
application process. There may be multiple sets of OSI communication 
functions in an application process, so a single application process 
may be represented by multiple application entities. However, each 
application entity represents a single application process. An 
application entity contains a set of communication capabilities 
called "application service elements." An application service element 
is a coherent set of integrated functions. These application service 
elements may be used independently or in combination. Examples of 
application service elements are X.400, FTAM, ACSE, ROSE, and CMISE. 


When communication is reguired between two application entities, one 
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or more "application associations" are established between them. 

Such an association can be viewed as a connection at the level of the 
application layer. An "application context" defines the set of 
application service elements which may be invoked by the user of an 
application association. The application context may prescribe one 
or more application service elements. 


Generally, an "application layer protocol" is realized by the use of 
the functionality of a number of application service elements. This 
functionality is provided by the specification of a set of 
application protocol data units (APDUs) and the procedures governing 
their use. In general, the operation of an application layer 
protocol may reguire the combination of APDUs from different 
application service elements. The application entity makes direct 
use of presentation context identifiers for the specification and 
identification of APDUs. 


3.3.1. ACSE 


The Association Control Service Element (ACSE) is used to establish 
and release associations between application entities. Before any 
management operations can be performed using CMIP, it is necessary 
for the two application entities involved to form an association. 
Either the manager or the agent can initiate association 
establishment. ACSE allows the manager and agent to exchange 
application entity titles for the purpose of identification and 
application context names to establish an application context. As 
stated above, an application context defines what service elements 
(for instance, ROSE and CMISE) may be used over the association. 
After the association is established, ACSE is not used again until 
the association is released by the manager or agent. 


3.3.2. ROSE 


The Remote Operation Service Element (ROSE) is the ISO equivalent of 
remote procedure call. ROSE allows the invocation of an operation to 
be performed on a remote system. The Remote Operation protocol 
contains an invoke identifier for correlating requests and responses, 
an operation code, and an argument field for parameters specific to 
the operation. ROSE can only be invoked once an application 
association has been established. CMIP uses the transaction-oriented 
services provided by ROSE for all its requests and responses. CMIP 
also uses the error response facilities provided by ROSE. 


3.3.3.  CMISE 


The Common Management Information Service Element (CMISE) is the 
service element that provides the basic management services. The 
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CMISE is a user of both ROSE and ACSE. The CMISE provides both 
confirmed and unconfirmed services for reporting events and 
retrieving and manipulating management data. These services are used 
by manager and agent application entities to exchange management 
information. Table 1 provides a list of the CMISE services. In 
addition, the CMISE also provides the ability to issue a series of 
(multiple) linked replies in response to a single request. 


g 4------------------------- + 
| Service | Type | 
g 4------------------------- + 
| M-INITIALISE | confirmed 

| M-TERMINATE | confirmed 

| M-ABORT | non-confirmed 


M-EVENT-REPORT confirmed/non-confirmed 
M-GET confirmed 


| M-SET | confirmed/non-confirmed | 
| M-ACTION | confirmed/non-confirmed | 
| M-CREATE | confirmed 
| M-DELETE | confirmed 
+----------------- +------------------------- + 


Table 1. CMISE Service Summary 


CMIS services can be divided into two main classes: management 


association services and information transfer services. Furthermore, 
there are two types of information transfer services: management 
notification services and management operation services. In addition 


to the other CMIS services, the CMISE provides facilities that enable 
multiple responses to confirmed operations to be linked to the 
operation by the use of a linked identification parameter. 


3.3.3.1. Management Association Services 


CMIS provides services for the establishment and release of 
application associations. These services control the establishment 
and normal and abnormal release of a management association. These 
services are simply pass-throughs to ACSE. 


The M-INITIALISE service is invoked by a CMISE-service-user to 
establish an association with a remote CMISE-service-user for the 
purpose of exchanging management information. A reply is expected. 
(A CMISE-service-user is that part of an application process that 
makes use of the CMISE.) 


The M-TERMINATE service is invoked by a CMISE-service-user to release 
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an association with a remote CMISE-service-user in an orderly manner. 
A reply is expected. 


The M-ABORT service is invoked by a CMISE-service-user or a CMISE- 
service-provider to release an association with a remote CMISE- 
service-user in an abrupt manner. 


3.3.3.2. Management Notification Services 


The definition of notification and the consequent behavior of the 
communicating entities is dependent upon the specification of the 
managed object which generated the notification and is outside the 
scope of CMIS. CMIS provides the following service to convey 
management information applicable to notifications. 


The M-EVENT-REPORT service is invoked by a CMISE-service-user to 
report an event about a managed object to a remote CMISE-service- 
user. The service may be requested in a confirmed or a non-confirmed 
mode. In the confirmed mode, a reply is expected. 


3.3.3.3. Management Operation Services 


The definition of the operation and the consequent behavior of the 
communicating entities is dependent upon the specification of the 
managed object at which the operation is directed and is outside the 
scope of CMIS. However, certain operations are used frequently 
within the scope of management and CMIS provides the following 
definitions of the common services that may be used to convey 
management information applicable to the operations. 


The M-GET service is invoked by a CMISE-service-user to request the 
retrieval of management information from a remote CMISE-service-user. 
The service may only be requested in a confirmed mode. A reply is 
expected. 


The M-SET service is invoked by a CMISE-service-user to request the 
modification of management information by a remote CMISE-service- 
user. The service may be requested in a confirmed or a non-confirmed 
mode. In the confirmed mode, a reply is expected. 


The M-ACTION service is invoked by a CMISE-service-user to request a 
remote CMISE-service-user to perform an action. The service may be 

requested in a confirmed or a non-confirmed mode. In the confirmed 

mode, a reply is expected. 


The M-CREATE service is invoked by a CMISE-service-user to request a 


remote CMISE-service-user to create another instance of a managed 
object. The service may only be requested in a confirmed mode. A 
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reply is expected. 


The M-DELETE service is invoked by a CMISE-service-user to reguest a 
remote CMISE-service-user to delete an instance of a managed object. 
The service may only be reguested in a confirmed mode. A reply is 
expected. 


4. The CMOT Architecture 


The CMOT (CMIP Over TCP/IP) architecture is based on the OSI 
management framework [15] and the models, services, and protocols 
developed by ISO for network management. The CMOT architecture 
demonstrates how the OSI management framework can be applied to a 
TCP/IP environment and used to manage objects in a TCP/IP network. 
The use of ISO protocols for the management of widely deployed TCP/IP 
networks will facilitate the ultimate migration from TCP/IP to ISO 
protocols. The concept of proxy management is introduced as a useful 
extension to the architecture. Proxy management provides the ability 
to manage network elements that either are not addressable by means 
of an Internet address or use a network management protocol other 
than CMIP. 


The CMOT architecture specifies all the essential components of a 
network management architecture. The OSI management framework and 
models are used as the foundation for network management. A 
protocol-dependent interpretation of the Internet SMI [2] is used for 
defining management information. The Internet MIB [3] provides an 
initial list of managed objects. Finally, a means is defined for 
using ISO management services and protocols on top of TCP/IP 
transport protocols. Management applications themselves are not 
included within the scope of the CMOT architecture. What is 
currently standardized in this architecture is the minimum required 
for building an interoperable multivendor network management system. 
Applications are explicitly left as a competitive issue for network 
developers and providers. 


4.1. Management Models 
The following sections indicate how the CMOT architecture applies the 
OSI managements models and point out any limitations the CMOT 
architecture has as it is currently defined in this memo. 


4.1.1. The Organizational Model 


It is beyond the scope of this memo to define the relations and 


interactions between different management domains. The current CMOT 
architecture concerns itself only with the operations and 
characteristics of a single domain of management. The extension of 
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the mechanisms defined here to include multiple domains is left for 
further study. 


4.1.2. The Functional Model 


The CMOT architecture provides the foundation for carrying out 
management in the five functional areas (fault, configuration, 
performance, accounting, and security), but does not address 
specifically how any of these types of management are accomplished. 
It is anticipated that most functional requirements can be satisfied 
by CMIS. The greatest impact of the functional requirements in the 
various areas will likely be on the definition of managed objects. 


4.1.3. The Information Model 


There are two different SMI specifications that are important to the 
CMOT architecture. The first is the SMI currently being defined by 
ISO [19]. This SMI is important to the CMOT approach because the ISO 
management protocol CMIP has been designed with the ISO model of 
management information in mind. The second SMI of importance is the 
that defined by the IETF MIB working group for use in defining the 
Internet MIB [3]. This Internet SMI, which is loosely based on a 
simplified version of the ISO SMI, is important because the managed 
objects defined for TCP/IP networks to be used by CMOT are defined in 
terms of it. Thus, in order to make the CMOT architecture complete, 
it will be necessary to show how the Internet SMI maps into CMIP in 
such a way as to enable it to convey the management information 
defined in the Internet MIB. This is done in the section devoted to 
management information (section 5). 


4.2. Protocol Architecture 


The objective of the CMOT protocol architecture is to map the OSI 
management protocol architecture into the TCP/IP environment. The 
model presented here follows the OSI model at the application layer, 
while using Internet protocols at the transport layer. The ISO 
application protocols used for network management are ACSE, ROSE, and 
CMIP. Instead of implementing these protocols on top of the ISO 
presentation, session, and transport layer protocols, the protocol 
data units (PDUs) for ACSE, ROSE, and CMIP are carried using the 
Internet transport protocols UDP [20] and TCP [21]. This is made 
possible by means of the lightweight presentation protocol defined in 
RFC 1085 [13] that maps ROSE and ACSE onto TCP/UDP/IP. The use of 
Internet transport protocols is transparent to network management 
applications, since they are presented with real ISO services. 
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4.2.1. The Lightweight Presentation Layer 


Given that it is desired to put ISO application protocols on top of 
TCP/IP, how is this best accomplished? It is necessary somehow to 
fill the "gap" between the ISO protocols (ACSE and ROSE) and the 
Internet protocols (UDP and TCP). Two basic approaches were 
considered. 


One possible approach [23] is to extend the ISO portion of the 
protocol stack down to the transport layer. The ISO Transport 
Protocol Class 0 (TP 0) then uses TCP instead of an ISO network 
protocol. Effectively, this treats TCP as a reliable network 
connection analogous to X.25. This approach allows us to operate 
"standard" ISO applications over TCP regardless of their service 
requirements, since all ISO services are provided. In this case, 
network management is just another such application. The major 
drawback with this approach is that full ISO presentation, session, 
and transport layers are expensive to implement (both in terms of 
processing time and memory). 


Another approach is presented in RFC 1085. Since the service 
elements required for network management (ACSE, ROSE, CMISE) do not 
require the use of full ISO presentation layer services, it is 
possible to define a "streamlined" presentation layer that provides 
only the services required. This lightweight presentation protocol 
(LPP) allows the use of ISO presentation services over both TCP and 


UDP. This approach eliminates the necessity of implementing ISO 
presentation, session, and transport protocols for the sake of doing 
ISO network management in a TCP/IP environment. This minimal 


approach is justified because this non-ISO presentation protocol used 
is very small and very simple. Thus, the LPP defined in RFC 1085 
provides a compact and easy to implement solution to the problem. 

The resulting CMOT protocol stack is shown in Figure 1. 
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Manager Agent 
4----------------------- + 4+----------------------- + 
Hook +----+ +----- + <------- > +----+ 4----+ +----- + 
| |ACSE| |ROSE| |CMISE| | CMIP | |ACSE| |ROSE| |CMISE| | 
| +----+ +----+ +----- + | | +----+ +----+ +----- + | 
| | | | 
4+----------------------- + 4----------------------- + 
| LPP | | LPP | 
4+----------------------- + 4----------------------- + 
| TCP UDP | | TCP UDP | 
4+----------------------- + 4----------------------- + 
| IP | | IP | 
4+----------------------- + 4+----------------------- + 
| Link | | Link | 
4----------------------- + 4----------------------- + 
| | 
| | 
| | 

Network 


Figure 1. The CMOT Protocol Architecture 


It is important to note that the presentation services provided by 
the LPP are "real" (but minimal) ISO presentation services [24]. 
This provides a clear migration path to "full ISO" in the future. 
Such a migration would be accomplished by substituting ISO protocols 
for the Internet protocols TCP, UDP, and IP [25], and replacing the 
LPP with ISO presentation and session protocols. No changes will be 
required in the ISO application layer protocols. For this reason, 
investments in application development will be well preserved. 


4.2.2. The Quality of Transport Service 


The quality of transport service needed for network management 
applications is an issue that has caused much controversy, yet it has 
never been resolved. There are two basic approaches: datagram- 
oriented and connection-oriented. There are advantages and 
disadvantages to both of these two approaches. While the datagram- 
oriented approach is simple, requires minimal code space, and can 
operate under conditions where connections may not be possible, the 
connection-oriented approach offers data reliability and provides 
guaranteed and consistent service to the driving application. 


This memo does not take sides on this issue. Rather it passes such 
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resolution to the network management applications, which are 
ultimately the point where the reguirements from the underlying 
service need to be determined. As such, the CMOT protocol 
architecture provides both services. The presentation layer service 
allows the application to select either high or low guality service 
for the underlying transport. Depending on this choice, the LPP will 
use either UDP (low guality) or TCP (high guality) to establish the 
application association and carry the application data. It is 
important, however, for the application to be aware of the quality of 
service that it is using: low quality means low quality! The use of 
an unreliable transport like UDP necessarily puts more burden on the 
application. 


4.3. Proxy Management 


Proxy is a term that originated in the legal community to indicate an 
entity empowered to perform actions on behalf of another. In our 
context, a proxy is a manager empowered to perform actions on behalf 
of another manager. This may be necessary because the manager cannot 
communicate directly with the managed devices either for security or 
other administrative reasons or because of incompatible communication 
mechanisms or protocols. In either case, the proxy assumes the agent 
role with respect to the requesting manager and the manager role with 
respect to the managed device. 


Some network elements, such as modems or bridges, may not be able to 
support CMIP and all the associated protocols. In addition, such 
devices may not have Internet addresses. Such devices are called 
"limited systems". It may be possible to manage these devices using 
proprietary mechanisms or other standard protocols (such as the IEEE 
802.1 management protocol for managing bridges). In cases where it 
is desirable to integrate the management of such devices with the 
overall CMOT management of an internet, it is necessary to use proxy 
management. Some network elements that are not "limited systems" as 
described above may still benefit from the use of proxy management. 
If the management protocol supported by such a system is proprietary 
or some standard protocol other than CMIP (such as SNMP), then CMOT 
proxy management can be used to integrate the management of such 
systems. 


A proxy operates in the following manner. When a CMOT manager wants 
to send a request to a managed device that it cannot communicate with 
directly, it routes the request to the proxy. The proxy maps the 
CMIP request into the information schema understood by the managed 
device and sends the appropriate request to the managed device using 
the native management protocol of the device. When the proxy 
receives the response from the managed device, it uses CMIP to return 
the information to the manager that made the original request. 
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The use of proxy management can be largely transparent to the 
reguesting manager, which appears to be exchanging information 
directly with the selected device. The only thing that is known to 
the manager is that additional "instance" information is reguired to 
select a particular device managed by the proxy. Each proxy may 
support many managed devices, using the "instance" information to 
multiplex CMIP requests and responses among them. The mapping 
between a specific instance and an actual managed device is a local 
matter. (The use of the CMIP Object Instance field to select a 
particular system to manage by proxy is explained below in section 
Dia Dus: 2 25,) 


A proxy may also serve as an "intermediate manager" in another less 
transparent sense. The proxy manager may be requested to calculate 
summary statistics on information gathered from many different 
managed systems (e.g., the average number of PDUs transmitted or the 
distribution of PDUs transmitted over time). The proxy may be 
requested to log events transmitted by the managed systems under its 
control and to send to the requesting manager only those events of 
specific types. When this use of proxy management is made, the 
conceptual schema for managed objects known to both the requesting 
manager and proxy must include definitions of these aggregate managed 
objects (i.e., objects that do not belong to any one managed system). 
How the aggregate statistics would be calculated and logging 
performed based on information from the different devices managed by 
the proxy would be part of the definition of these aggregate managed 
objects. 


4.4. Directory Service 


RFC 1085 specifies the use of a minimal (or "stub") directory 
service. It specifies how the service name for an OSI application 
entity is converted into an "application entity title." The 
application entity title is then mapped into a presentation address. 
The form of a service name, an application entity title, and a 
presentation address can be found in RFC 1085. 


5. Management Information 


The description of management information has two aspects. First, a 
structure of management information (SMI) defines the logical 
structure of management information and how it is identified and 
described. Second, the management information base (MIB), which is 
specified using the SMI, defines the actual objects to be managed. 
The purpose of this section is to show how CMIP is used in the CMOT 
architecture to convey information defined in the Internet MIB. 
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5.1. The Structure of Management Information 


The SMI supplies the model for understanding management information, 
as well as templates and ASN.1 macros that can be used for defining 
actual management information. The following sections discuss the 
ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI 
in terms of the ISO SMI so that CMIP can be used to carry management 
information defined in terms of the Internet SMI. 


5.1.1. The ISO SMI 


The ISO SMI [19] is based on the abstraction of a "managed object" 
and the various kinds of relationships objects can be involved in. 
The following discussion does not purport to be a complete and 
accurate description of the latest ISO SMI work. It is intended to 
be a clear presentation of the basic ISO SMI concepts essential for 
understanding the CMIP-specific interpretation of the Internet SMI 
presented in section 5.3. 


5.1.1.1. Managed Objects and Attributes 


Management Information is modeled using object-oriented techniques. 
All "things" in the network that are to be managed are represented in 
terms of managed objects. A "managed object" is an abstraction (or 
logical view) for the purposes of network management of a 
"manageable" physical or logical resource of the network. In this 
context, "manageable" means that a particular resource can be managed 
by using CMIP. Examples of managed objects are protocol entities, 
modems, and connections. 


Each managed object belongs to a particular object class. An "object 
class" represents a collection of managed objects with the same, or 
similar, properties. A particular managed object existing in a 
particular network is defined as an "object instance" of the object 
class to which it belongs. Thus, an object instance represents an 
actual realization of an object class (i.e., a managed object of a 
particular class bound to specific values). An example of an object 
class is "transport connection." In an actual network, there are a 
number of managed objects (specific transport connections) that are 
instances of this class. In summary, a managed object type, which is 
called an "object class," is the collection of all actual and 
potential instances of that type. 


Managed objects are fully defined by specifying the "attributes" or 
properties the object has, the CMIS operations that can be performed 
on the object (e.g., M-SET, M-CREATE) and any constraints on those 
operations, specific actions (e.g., self-test) that can be performed 
on the object, events that the object can generate, and information 
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about various relationships the object may be involved in. All of 
this information relevant to a managed object is typically provided 
by filling in an object template. 


Managed objects contain properties that are referred to as 
attributes. Attributes are atomic items of information that can only 
be manipulated as a whole. An example of an attribute is a counter 
providing a specific piece of information, such as the number of 
packets retransmitted. 


Each object class and attribute is assigned a unique identifier (an 
ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration 
authority. 


5.1.1.2. Management Information Hierarchies 


Managed objects participate in relationships with each other. There 
are two relationships that are of particular importance for 
management information: the containment relationship and the 
inheritance relationship. These relationships can be used to 
construct hierarchies of managed objects. In addition, there is 
another hierarchy defined by the registration process for registering 
identifiers for object classes and attributes. 


5.1.1.2.1. The Registration Hierarchy 


The registration hierarchy is determined by the ASN.1 registration 
tree [5] for assigning OBJECT IDENTIFIERS. An OBJECT IDENTIFIER is 
an administratively assigned name composed of a series of integers 
traversing a path from the root of the ASN.1 registration tree to the 
node or leaf to be identified. For example, the sequence of integers 
( iso(1) standard(0) ips-osi-mips(9596) cmip(2) ) (1.0.9596.2) can be 
used to uniquely identify the CMIP standard. Each node of this tree 
has an associated registration authority that determines how numbers 
in the subtree defined by that node are allocated. In the context of 
management, these OBJECT IDENTIFIERs are used for identifying object 
classes and attributes. The registration hierarchy is not based on 
any particular relationship between managed objects or between 
managed objects and their attributes. It is independent of both the 
inheritance and containment relationships described below. Its 
purpose is simply to generate universally unique identifiers. 


5.1.1.2.2. The Containment Hierarchy 


The containment hierarchy is constructed by applying the relationship 
"is contained in" to objects and attributes. Objects of one class 
may contain objects of the same or different class. Objects may also 
contain attributes. Attributes cannot contain objects or other 
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attributes. For example, objects of the class "transport entity" may 
contain objects of the class "transport connection"; an object of the 
class "management domain" may contain objects of the class "node." An 
object class that contains another object class is called the 
"superior" object class; an object class that is contained in another 
object class is called the "subordinate" object class. The 
containment relationships that an object may participate in are part 
of the definition of the object class to which that managed object 
belongs. All object classes (except the topmost) must have at least 
one possible superior in the containment tree. The definition of a 
class may permit it to have more than one such superior. However, 
individual instances of such a class are nevertheless contained in 
only one instance of a possible containing class. 


The containment hierarchy is important because it can be used for 
identifying instances of a managed object. For example, assume there 
is an object class "domain" that contains an object class "node" that 
contains an object class "transport entity" that contains an object 
class "transport connection." A particular instance of a transport 
connection can be identified by the concatenation of "instance 
information" for each object class in the containment path: ( 
domain="organization," node="herakles," transport entity=tp4, 
transport connection=<TSAP-AddressA, TSAP-AddressB> ). 


What constitutes appropriate "instance information" for each object 
class is part of the definition of that object class and is known as 
the "distinguished attribute(s)." A distinguished attribute is 
composed of an OBJECT IDENTIFIER naming the attribute and the value 
of the attribute. For each object class, the distinguished 
attributes that differentiate instances of that class are 
collectively called the "relative distinguished name." A sequence of 
relative distinguished names (one for each class in the containment 


path) is the "distinguished name" of a managed object. The example 
given above represents the distinguished name of a transport 
connection. The containment hierarchy is sometimes referred to as 


the "naming tree", because it is used to "name" a particular instance 
of a managed object. 


The containment relationship also defines an existence dependency 
among its components; an object or attribute can "exist" only if the 
containing object also "exists." Deletion of an object may result in 
deletion of all objects and attributes contained within it. 
Alternately, depending on the definition of the managed object, 
deletion may be refused until all contained managed objects have been 
deleted. 
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5.1.1.2.3. The Inheritance Hierarchy 


Vis 


1 


The inheritance hierarchy is constructed by applying the relationship 
"inherits properties of" to object classes. An object class may 
inherit properties of another object class; refinement is obtained by 
adding additional properties. In this relationship, the parent class 
is called the "superclass" and the inheriting class the "subclass." 
For example, the class "layer entity" may be a superclass of "network 
entity," which in turn is a superclass of "X.25 network entity." 
Attributes defined for "network entity" (e.g., the number of packets 
sent) are automatically defined for "X.25 network entity" without 
having to explicitly include them in the definition for the class 
"X.25 network entity." Thus, inheritance serves as a shorthand for 
defining object classes using object-oriented methodology. Each 
class (except the topmost) has at least one superclass, but may have 


zero, one, or many subclasses. Subclasses may in turn have further 
subclasses, to any degree. A special object called "top" is the 
ultimate superclass. It has no properties of its own. 


The inheritance hierarchy has no relevance to the naming of object 
instances. It is useful only insofar as it leads to a manageable and 
extensible technique for the definition of object classes. 


.2. The Internet SMI 


The Internet SMI [2] is designed to be a protocol-independent SMI 
that can be used with both SNMP and CMIP. For this reason, it is 
necessary for any management protocol that uses this SMI to show how 
it is to be interpreted in a protocol-specific manner. This is done 
for CMIP in this memo. 


The Internet SMI indicates both how to identify managed objects and 
how to define them. The Internet SMI defines a registration subtree 
rooted at ( iso(1) org(3) dod(6) internet (1) ) for the sake of 
registering OBJECT IDENTIFIERs to be used for uniquely identifying 
managed objects. The current Internet SMI specifies the format for 
defining objects in terms of an "object type" template and an 
associated OBJECT-TYPE ASN.1 macro. An object type definition 
contains five fields: a textual name, along with its corresponding 
OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of 
the object type; an access (read-only, read-write, write-only, or 
not-accessible); and a status (mandatory, optional, or obsolete). 
The current Internet SMI does not provide any mechanism for defining 
actions or events associated with a managed object. 


In describing management information, the current Internet SMI does 
not use the notions of "object class" and "attribute" found in the 
ISO SMI. Only the concepts of "object type" and "object instance" 
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are used. The Internet SMI shows how to define object types; it 
leaves the specification of object instances as a protocol-specific 
matter. The current Internet structure of management information is 
simpler and less rich than the corresponding ISO structure. The ISO 
SMI makes a distinction between simple "attributes," which can be 
viewed as "leaf objects" that are the lowest elements of the 
containment hierarchy, and composite "managed objects" that belong to 
an "object class" and have a structure associated with them (that is, 
can contain attributes). The Internet SMI does not draw this 
distinction; both simple and composite "objects" are defined as 
"object types." What structure is associated with objects in the 
Internet SMI is defined through the deliberate attempt to structure 
the lower part of the Internet registration tree according to 


containment principles. (Objects that are considered "attributes" of 
other containing objects are defined directly below them in the 
object registration tree.) This results in a certain lack of 


flexibility, since the registration hierarchy is implicitly used to 
define the containment hierarchy. This means that the Internet SMI 
does not contain a mechanism for defining containment relationships 
that do not happen to coincide with the registration hierarchy. In 
interpreting the Internet SMI for use with CMIP, it is necessary to 
overcome this limitation. 


5.2. The Management Information Base 


The Management Information Base (MIB) is a "conceptual repository of 
management information." It is an abstract view of all the objects in 
the network that can be managed. Note that the MIB is conceptual in 
that it does not carry any implications whatsoever about the physical 
storage (main memory, files, databases, etc.) of management 
information. The SMI provides the guidelines for defining objects 
contained in the MIB. 


The CMOT approach will use the Internet MIB based on the Internet SMI 
described above. The first version of the Internet MIB, which is the 
product of the IETF MIB working group, is defined in RFC 1066 [3]. 

It contains objects divided into eight groups: system, interfaces, 
address translation, IP, ICMP, TCP, UDP, and EGP. In addition, the 
Internet SMI provides for future versions of the Internet MIB and a 
means for otherwise extending the MIB through the registration of 
managed objects under "private" and "experimental" branches of the 
object registration tree. Appendix B provides a protocol-specific 
interpretation of the first version of the TCP/IP MIB defined in [3] 
so that it can be used with CMOT. This interpretation is based on a 
straightforward mapping of the current Internet SMI to the ISO SMI 
(section 5.3). 


The initial version of the Internet MIB concentrates on defining 
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objects associated with various Internet protocols. It is expected 
that future versions of the Internet MIB and various extensions will 
provide a much richer set of objects to manage, including management 
information about a variety of network devices and systems. Thus, an 
expanded MIB will allow wide-ranging and powerful management using 
the CMOT approach. 


5.3. An Interpretation of the Internet SMI 


In order to use CMIP to convey information defined in terms of the 
Internet SMI, it is necessary to show how object instances are 
specified and to provide the necessary structure for differentiating 
object class and attributes. These objectives are both met by 
separating the containment hierarchy used for naming objects from the 
registration hierarchy and by imposing an "object class" structure on 
the Internet SMI. Using the technique of imposing an object class 
structure does not replace or redefine the object definitions in the 
Internet MIB; it merely provides a necessary gloss or commentary on a 
MIB defined in terms of the Internet SMI. For example, Appendix B 
references the "object type" definitions found in [3], but imposes 
additional structure on them. 


This object class definition derives from a simplified version of the 


OBJECT-CLASS macro defined in the ISO SMI [19]. The more complex 
definition is not needed for present purposes. (The object class 
definition presented here could be extended in the future to show 
what actions and events are associated with a managed object.) The 


object class definition has the following fields: 


OBJECT CLASS: 


A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object 
class, along with its corresponding OBJECT IDENTIFIER. 


Definition: 
A textual description of the object class. 


Subclass Of: 
The OBJECT CLASS DESCRIPTOR of the object class that is the 
superclass of this object class. This field is used for indicating 
the inheritance relationship. 


Superiors: 
A list of OBJECT CLASS DESCRIPTORs of the possible superior object 
classes of this object class. This field is used for indicating 
the containment relationship. 
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Ses 


Names: 


A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are 
the distinguished attributes of this object class. (The OBJECT- 
TYPE macro is defined in RFC 1065). Attributes listed here will 
normally be present in the Attribute field of the object class 
definition. This field is used for indicating what attributes 
must be present in the relative distinguished name that indicates 
an instance of this object class. 


Attributes: 


La 


A list of OBJECT DESCRIPTORS identifying the OBJECT TYPES that are 
attributes of this object class. (The OBJECT-TYPE macro is defined 
in RFC 1065). This field is used for indicating the attributes 
that are contained in this object class. 


This object class definition satisfies our objectives for 
interpreting the Internet SMI for use by CMIP. The Attributes 
field shows what attributes are contained in this object class; 
this makes the necessary distinction between object classes and 
attributes required by CMIP. Instead of referencing an 
"attribute" def inition (as is done in the ISO SMI), the 
Attributes field references the "object type" definition found in 
RFC 1065 and used to define the Internet-standard MIB in RFC 1066. 
The name, syntax, and access information required for attributes 
is contained in the "object type" definition. Two things are 
required for specifying an instance of a managed object: a 
containment relationship determining a sequence of object classes 
and a means for specifying the distinguished attributes for an 
object class. The Superiors field makes the containment 
relationship explicit; it is no longer merely a function of the 
registration tree. The Names field makes it possible to indicate 
the distinguished attributes for an object class required for 
giving instance information. Thus, the object class definition 
makes it possible to specify an object instance using CMIP. 


Object Class and Attributes 


The mapping of management information to the CMIS parameters Managed 
Object Class and Attribute Identifier List now becomes apparent. 


5.3.1.1. Object Class 


The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER 
assigned to the particular object class. For example, the Managed 
Object Class for the object class "ip" (as defined in Appendix B) is 


{ mib 4 ) = 1.3.6.1.2.1.4. 


Warrier £ Besaw [Page 25] 


RFC 1095 CMOT April 1989 


5.3.1.2. Attribute Identifier 


The CMIS Attribute Identifier List parameter is a list of Attribute 
Identifiers. An Attribute Identifier can be either global or local. 
If it is global, then it is the OBJECT IDENTIFIER assigned to the 
attribute (i.e., "object type") that is being indicated. For 
example, the global Attribute Identifier for the attribute 
"ipForwarding" (as defined in [3]) is 


rūpsl pe DO AE, 


If the Attribute Identifier is local, it is an integer that is the 
last component in the OBJECT IDENTIFIER identifying the object. For 
ipForwarding, the local Attribute Identifier is 1. In the case where 
the local identifier is used, the leading components of the OBJECT 
IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the 
containing object class. This is true for the interpreted Internet 
MIB defined in Appendix B, but may not be true generally. The local 
identifier is intended to be interpreted relative to the Managed 
Object Class field of the CMIP PDU. When a local Attribute 
Identifier is encountered in a CMIP PDU, the global form of the 
identifier is formed by prepending the OBJECT IDENTIFIER in the 
Managed Object Class field to the local identifier. This is valid 
only when scoping is not used (i.e., scoping is "baseObject"). If 
scoping is used, then the global form of the Attribute Identifier 
must be used instead of the local form. 


5.3.2. Management Information Hierarchies 


The following sections show how the three management information 
hierarchies are to be understood for the interpreted Internet SMI. 


5.3.2.1. The Registration Hierarchy 


The registration hierarchy is the global object registration tree 
described in [2]. It is used merely for assigning identifiers for 
object classes and attributes (i.e., "object types" in RFC 1065). 


5.3.2.2. The Containment Hierarchy 


As described above, the containment hierarchy is used to specify an 
object instance. The Names field of the object class definition 
contains the distinguished attributes for the object class. The 
OBJECT IDENTIFIER naming the "attribute" together with its value is 
called an attribute value assertion. A set of attribute value 
assertions (one for each distinguished attribute) is the relative 
distinguished name associated with that object class. The sequence 
of relative distinguished names for each of the object classes in the 
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containment hierarchy to which a managed object belongs is the 
distinguished name of the object. An object instance is fully 
specified by a distinguished name. 


Let us take a concrete example from Appendix B. How would we 
represent an instance of an entry in the IP routing table? We begin 
by examining the object class in question (ipRouteEntry) and use the 
Superiors field to find the superior class in the containment 
hierarchy (ipRoutingTable). This process continues until we 
construct the following containment path of object classes: system, 
ip, ipRoutingTable, ipRouteEntry. Now for each of these object 
classes, we inspect the Names field to find the distinguished 


attribute for that object class. If no Names field is present (as is 
the case for "ip" and "ipRoutingTable"), then no instance information 
is required at that level. Both "system" and "ipRouteEntry" have 


Name fields to show what information is expected at that level. With 
this information, we can construct the following distinguished name 
specifying an instance of an IP routing table entry: 


baseManagedObjectInstance ( 
distinguishedName ( 
relativeDistinguishedName ( —— system 
attributeValueAssertion ( 
attributeType ( cmotSystemID } 
attributeValue "gatewayl.acme.com" 
} 
J, 
relativeDistinguishedName ( -- ipRouteEntry 
attributeValueAssertion { 
attributeType { ipRouteDest } 
attributeValue 10.0.0.51 


If the system instance information is not present, then it is assumed 
to be the system with which the management association is established 
(i.e., the system receiving the request). 


Note that the object instance tree can contain components of the 


distinguished name that are outside the managed system (node). This 
enables referencing of objects across management domains (there could 
be an object class "domain") and across a collection of nodes. Ina 


network where several intermediate managers may be involved in a 
request, each intermediate manager Can use the "system" portion of 
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the name to determine where to send a reguest or result. This 
technigue of naming treats each intermediate managing system as a 
proxy manager. The proxy manager resolves the address of the next 
node in the chain and may use a different protocol to transfer the 
reguest or result. Thus, the "system" instance information can be 
used to name devices being managed by proxy. 


5.3.2.3. The Inheritance Hierarchy 


The Internet SMI does not use the inheritance relationship. The 
"Subclass Of" field is present in the object class definition to show 
how the inheritance relationship would be represented and to allow 
for future extensibility. It is not used for any of the object 
classes defined in Appendix B. 


5.4. Scoping, Filtering, and Synchronization 


Within some services, CMIS provides additional capabilities that are 
related to the SMI. These are the scoping, filtering, 
synchronization, and linked-reply facilities. The presence of these 
facilities are indicated by the Multiple Object Selection Functional 
Unit defined in CMIS [11]. 


These facilities provide the manager with the ability to operate on a 
collection of managed objects, rather than a single object. The 
selection of multiple objects occurs in two phases: scoping and 
filtering. Scoping is used to identify the managed objects to which 
a filter is to be applied. Then filtering is used to select a subset 
of managed objects that satisfy certain conditions. If scoping is 
not used, only the "base" managed object indicated by the CMIS 
Managed Object Class parameter is implied. An example of the use of 
scoping and filtering for selecting a particular managed object (a 
table entry) is given in one of the sample protocol exchanges found 
in Appendix C. 


5.4.1. Scoping 


Scoping is meant to be understood in terms of the containment 
hierarchy. A position at a certain level of the containment tree is 
defined by the CMIS Managed Object Class parameter. The CMIS Scope 
parameter is then interpreted relative to this "base" managed object 
(defined by both object class and object instance). The Scope 
parameter can be used to select the base object alone, all managed 
objects in the entire subtree (of the containment tree) below the 
base object, or all managed objects in the "n"th level (n = 1, 2, 
3,...) below the base object. 
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5.4.2. Filtering 


Within the objects selected as a result of the scope parameter, it is 
possible to further refine the selection of managed objects through 
the use of filtering. Filtering provides the ability to select a 
subset of these objects based on conditions applied to attributes 
(e.g., IP routing table entries with the "ipRouteAge > 100") and 
logical operations (and, or, not). 


5.4.3. Synchronization 


When multiple managed objects have been selected using scoping and 
filtering, the question of synchronization across object instances 
(such as multiple IP routing table entries) arises. The two possible 
choices are "best effort" and "atomic." If "best effort" 
synchronization is selected, the failure to apply an operation (e.g., 
M-SET) to one instance of an object does not affect the effort to 


apply this operation to other instances of the object. If "atomic" 
synchronization is selected, then the operation is either performed 
on all object instances selected or none. The default 


synchronization is best effort. 
5.4.4. Linked Replies 


If the reply to a single request for a set of managed objects results 
in more than one managed object being returned, all of these managed 
objects cannot be returned together in a single CMIP response PDU. 
The reason for this is that the structure of the CMIP response PDU 
only has a single field for containing object instance information. 
Since each managed object has its own instance information, each 
managed object must be returned in a separate CMIP PDU. In such a 
case, the CMIP Linked Reply PDU is used. The Linked Reply PDU 
provides a means of associating each of the multiple replies with the 
original request that generated them. Thus, a single CMIP Get 
Request PDU that uses scoping and filtering would result in zero or 
more CMIP Linked Reply PDUs being returned before a final CMIP Get 
Result PDU. 


A linked reply can also be used to segment a CMIP response pertaining 
to a single managed object. This would only be necessary if UDP is 
being used as the underlying transport and it is not possible to 
return all the information requested about the managed object in a 
single response PDU subject to the size limitations described in 
section 10.2. 


5.5. Accessing Tables 


This section explains how to use the interpreted Internet SMI and MIB 
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to access tables. 
5.5.1. Accessing Whole Tables 


A whole table is accessed by specifying the object class of the 
table, indicating a scoping level of one, and not providing an 
attribute identifier list. The CMIS standard [11] specifies that if 
the attribute identifier parameter is not present, then all attribute 
identifiers are assumed. The following CMIS parameters would be used 
to return the entire TCP connection table: 


Object Class: ( tcpConnTable ) 

Object Instance: "empty" (unless proxy management is used) 
Scope: onelevel (1) 

Filter: not present 

Attribute Identifier List: not present 


By scoping one level below "tcpConnTable, " all managed objects of the 
class "tcpConnEntry" are selected. (The object class "tcpConnEntry" 
is the only object class one level below the object class 
"tcpConnTable" in the containment hierarchy.) The absence of an 
attribute identifier list signals that all attributes of the managed 
object are to be returned (i.e., all fields of the TCP connection 
table entry). 


In reply to this request, each entry of the table will be returned in 
a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU). 
Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and 
the appropriate Object Instance information for that entry, as well 
as an Attribute List giving the values of each of the fields of the 
table entry. 


5.5.2. Accessing Table Entries 


An entire table entry is accessed by specifying the object class of 
the table entry, providing a distinguished name specifying the 
instance of the table entry, and not providing an attribute 
identifier list. As seen above, the absence of the attribute 
identifier list parameter indicates that all attributes are assumed. 
The absence of a scope parameter indicates that the base managed 
object class is intended. The following CMIS parameters would be 
used to return the entire IP routing table entry for which the field 
"ipRouteDest" has the value 10.0.0.51: 


Object Class: ( ipRouteEntry } 

Object Instance: { ipRouteDest, 10.0.0.51 ) 
Scope: not present 

Filter: not present 
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Attribute Identifier List: not present 


The result is returned in a single CMIP Get Result PDU with an 
attribute list consisting of all of the attributes (i.e., fields) of 
the table entry and their corresponding values. 


If the object class field refers to a table entry and no instance 


information is provided to select a particular entry, then a 
"noSuchObjectInstance" CMIP error should be returned. 
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6. 


6. 


Part II: Protocol Agreements 
CMOT Protocol Overview 
This part of the document is a specification of the protocols of the 


CMOT architecture. Contained herein are the agreements reguired to 
implement interoperable network management systems using these 


protocols. The protocol suite defined by these implementors” 
agreements will facilitate communication between eguipment of 
different vendors, suppliers, and networks. This will allow the 


emergence of powerful multivendor network management based on ISO 
models and protocols. 


The choice of a set of protocol standards together with further 
agreements needed to implement those standards is commonly referred 
to as a "profile." The selection policy for the CMOT profile is to 
use existing standards from the international standards community 
(ISO and CCITT) and the Internet community. Existing ISO standards 
and draft standards in the area of OSI network management form the 
basis of this CMOT profile. Other ISO application layer standards 
(ROSE and ACSE) are used to support the ISO management protocol 
(CMIP). To ensure interoperability, certain choices and restrictions 
are made here concerning various options and parameters provided by 
these standards. Internet standards are used to provide the 
underlying network transport. These agreements provide a precise 
statement of the implementation choices made for implementing ISO 
network management standards in TCP/IP-based internets. 


In addition to the Netman working group, there are at least two other 
bodies actively engaged in defining profiles for interoperable OSI 
network management: the National Institute of Science and Technology 
(NIST) Network Management Special Interest Group (NMSIG) and the OSI 
Network Management Forum. Both of these groups are similar to the 
Netman working group in that they are each defining profiles for 
using ISO standards for network management. Both differ in that they 
are specifying the use of underlying ISO protocols, while the Netman 
working group is concerned with using OSI management in TCP/IP 
networks. In the interest of greater future compatibility, the 
Netman working group has attempted to make the CMOT profile conform 
as closely as possible to the ongoing work of these two bodies. 


1. The CMOT Protocol Suite 


The following seven protocols compose the CMOT protocol suite: ISO 
ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation 
protocol (LPP), UDP, TCP, and IP. The relation of these protocols to 
each other is briefly summarized in Figure 2. 
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FO aaa + 
Management Application Processes 

PO aaa + 

+------------------- + 

| CMISE 

| ISO DIS 9595/9596 | 

+------------------—- + 
Ho ooo + +-------------------- + 
| ACSE | | ROSE | 
| ISO IS 8649/8650 | | ISO DIS 9072-1/2 | 
+------------------ + $ ooo + 
$ aaa + 

Lightweight Presentation Protocol (LPP) 
RFC 1085 

HO aaa + 
+------------------ + $ ooo + 
| TCP | | UDP | 
| RFC 793 | | RFC 768 | 
+------------------ + +-------------------- + 
$ aaa + 
| IP | 
| RFC 791 | 
PO aa + 


Figure 2. The CMOT Protocol Suite 
6.2. Conformance Requirements 


A CMOT-conformant system must implement the following protocols: 
ACSE, ROSE, CMIP, LPP, and IP. A conformant system must support the 
use of the LPP over either UDP or TCP. The use of the LPP over both 
UDP and TCP on the same system may be supported. A conformant system 
need not support all CMIS operations. A conformant system must, 
however, support at least one of the functional unit groups 
(indicating a set of supported services) defined in section 7.1.3. 
The service and protocol selections are described in greater detail 
in the following sections. 


6.3. Abstract Syntax Notation 
The abstract syntax notation for all of the application service 


elements of the CMOT protocol suite is Abstract Syntax Notation One 
(ASN.1) [5]. The LPP is also defined using ASN.1. The basic 
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encoding rules used for ASN.1 are specified in [6]. Both definite- 
length and indefinite-length encodings are expressly permitted. 


7. Common Management Information Service Element 


The Common Management Information Service Element (CMISE) is 
specified in two ISO documents. The service definition for the 
Common Management Information Service (CMIS) is given in ISO DIS 
9595-2 [11]. The protocol specification for the Common Management 
Information Protocol (CMIP) is found in ISO DIS 9596-2 [12]. 


7.1. CMIS Services 
7.1.1. CMIS Services Overview 


All of the CMIS services listed in Table 1 are allowed with the CMOT 
approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET, 
M-SET, M-ACTION, M-CREATE, and M-DELETE. The specific services 
supported by a system will be determined by the functional unit group 
or groups to which a system belongs. 


7.1.2. Functional Units 


The CMIS services supported are designated in terms of functional 
units [11]. Bach functional unit corresponds to the invoker or 
performer aspect of a particular service. (The terms "invoker" and 
"performer" are taken from ROSE and refer to the caller of and 
responder to a remote operation, respectively.) The "stand alone" 
functional units associated with each of the management services are 


given in Table 2 as functional units 0-17. The number following the 
name of each functional unit in the table is defined by CMIP [12] to 
identify that particular functional unit. The functional units are 


used by the CMISE-service-user at the time of association 
establishment to indicate which services it is willing to support. 
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4+--------------------------------- 4------------------------ 4+------ + 
| Functional Unit | Service Primitives | Mode | 
4--------------------------------- 4------------------------ +=————— + 
| conf. event report invoker (0) | M-EVENT-REPORT Req/Conf | C | 
| conf. event report performer (1) | M-EVENT-REPORT Ind/Rsp | C | 
| event report invoker (2) | M-EVENT-REPORT Req | U 
| event report performer (3) | M-EVENT-REPORT Ind | U | 
| confirmed get invoker(4) | M-GET Reg/Conf | N/A | 
| confirmed get performer (5) | M-GET Ind/Rsp | N/A | 

confirmed set invoker (6) M-SET Req/Conf C 
| confirmed set performer (7) | M-SET Ind/Rsp Es 
| set invoker (8) | M-SET Reg | U | 
| set performer (9) | M-SET Ind | u | 
| confirmed action invoker(10) | M-ACTION Reg/Conf | C | 
| confirmed action performer (11) | M-ACTION Ind/Rsp (8 | 
| action invoker (12) | M-ACTION Reg U 
action performer (13) M-ACTION Ind U 
| confirmed create invoker (14) | M-CREATE Req/Conf | N/A | 
| confirmed create performer(15) | M-CREATE Ind/Rsp | N/A | 
| confirmed delete invoker(16) | M-DELETE Reg/Conf | N/A | 
| confirmed delete performer(17) | M-DELETE Ind/Rsp | N/A | 
| multiple reply (18) | Linked Identification | N/A 
multiple object selection(19) Scope, Filter, Sync. N/A 
| extended service (20) | Extended Presentation | N/A | 
4+--------------------------------- 4------------------------ +------ + 
C = confirmed, U = non-confirmed, N/A = not applicable 


Table 2. Functional Units 

In addition to the stand alone functional units, there are three 
additional functional units. If any of these additional functional 
units are selected, then at least one of the stand alone functional 
units must be selected. The multiple reply functional unit makes 
available the use of the linked identification parameter in the 
selected stand alone functional units. This makes possible the use 
of linked reply (multiple CMIP PDU responses to a single request). 
The multiple object selection functional unit makes available the use 
of the scope, filter, and synchronization parameters in the selected 
stand alone functional units. If the multiple object selection 
functional unit is selected, then the multiple reply functional unit 
must also be selected. The extended services functional unit makes 
available presentation layer services in addition to the P-DATA 
service. Selecting this functional unit has no effect in the context 
of CMOT, since the lightweight presentation layer provides only 
minimal ISO presentation services. 
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7.1.3. Functional Unit Groups 


In order to assist in the reduction of code size and complexity for 
different types of devices, a number of "functional unit groups" have 
been defined. Each of these groups indicates a set of services 
defined for either a manager or an agent. The "negotiation" 
concerning which functional unit groups are supported is done by 
means of the Functional Units parameter of the M-INITIALISE service 
(see section 7.1.4.1). There are five functional unit groups for 
managers: Event Monitor, Monitoring Manager, Simple Manager, 
Controlling Manager, and Full Manager. Each functional unit group is 
a superset of the preceding group. There are five functional unit 
groups for agents: Event Sender, Monitored Agent, Simple Agent, 
Controlled Agent, and Full Agent. Again, each functional unit group 
is a superset of the preceding group. The operations supported for 
each functional unit group are summarized in Table 3. 


$ Ho +>———— ===> Ho E +>———— Ho + 
| [Event | Get | Set |Create/|Action|Mult.|Mult. | 
[Functional Unit |Report | | |Delete | |Reply|Object | 
|Groups | | | | Select | 
+=>>>—>—>————————————— Ho +>———— ===> Ho Ho ===> +>————— + 
| 1. Event Monitor | U | no | no | no | no | no | no | 
| 2. Event Sender | U | no | no | no | no | no | no | 
| 3. Monitoring Mgr. | U | yes | no | no | no | no | no | 
| 4. Monitored Agent | U | yes | no | no | no | no | no | 
5. Simple Manager | U | yes | € | no | no | yes | no* | 
6. Simple Agent U yes C no no yes no* 
| 7. Controlling Mgr. | U | yes | U/C | yes | no | yes | yes | 
| 8. Controlled Agent | U | yes | U/C | yes | no | yes | yes | 
| 9. Full Manager | U/C | yes | U/C | yes | U/C | yes | yes | 
|10. Full Agent | U/C | yes | U/C | yes | U/C | yes | yes | 
a ae a E Ho ===> +>———— Ho Ho ===> Ho + 
C = confirmed, U = non-confirmed 


* Simple Managers and Agents must support "oneLevel" scoping for all 
and only those cases where it is reguired to access a whole table 
and may support synchronization other than "best effort"; no support 
for filtering is reguired. 


Table 3. Functional Unit Groups 


A conformant system must support at least one of these functional 
unit groups. A system may support both a manager group and an agent 
group. A system only needs to implement the services and service 
primitives required for the groups that it supports. In addition, a 
system may support services that are not required by any group that 
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it supports. 
7.1.4. M-INITIALISE Parameters 
The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service. 


The parameters for the M-INITIALISE service are defined in [11] and 
summarized in Table 4. 


$ Ho $22 + 
| Parameter Name | Reg/Ind | Rsp/Conf | 
$ Ho Ho + 
| Functional Units | Mandatory | Mandatory | 
| User Information | Optional | Optional 

| Access Control | Optional | Optional | 
E RE Ho Ho + 


Table 4. M-INITIALISE Parameters 


Notice that the further agreement has been made that the Functional 
Units parameter is mandatory at all times. The M-INITIALISE 
parameters are conveyed as ACSE user information in the ACSE request 
PDU. 


7.1.4.1. Functional Units 


The exchange of functional units between the initiating CMISE- 
service-user and the responding CMISE-service-user is required. This 
allows the CMIS-service-users to inform each other which functional 
units are supported. CMIP [12] defines a 21-bit BIT STRING to 
communicate which functional units are supported. A functional unit 


is supported if the corresponding bit in this bit string is one. The 
correspondence between functional units and functional unit groups is 
given in Table 5. The left column gives the functional unit 


corresponding to a particular bit position. The numbers along the top 
of the table indicate the functional unit group (the numbers of the 
functional unit groups are given in Table 3). The various columns 
indicate the value of each bit for a particular functional unit 
group. 
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y 
| 
+ 
|conf. event report invoker(0) | 
|conf. event report perf.(1) | 
|event report invoker (2) | 
[event report performer (3) | 
|confirmed get invoker (4) | 
confirmed get performer (5) | 
confirmed set invoker(6) 
[confirmed set performer (7) | 
|set invoker (8) 
|set performer (9) | 
| 
| 
| 
| 
| 
+ 
| 


| confirmed action invoker (10) 

| confirmed action performer (11) 
action invoker (12) 

action performer (13) 

| confirmed create invoker (14) 

| confirmed create performer (15) 
| confirmed delete invoker (16) 

| confirmed delete performer (17) 
multiple reply(18) 

multiple object selection(19) 
[extended service (20) 


, M = manager, A = agent 


Table 5. Functional Unit Group Values 


The "negotiation" using functional units proceeds as follows. The 
initiating CMISE-service-user (manager or agent) sends the functional 
units representing the functional unit group to which it belongs. 

The responding CMISE-service-user sends the functional units 
representing the functional unit group to which it belongs. (If an 
application process belongs to both a manager and an agent functional 
unit group, then both functional unit groups are indicated using the 
same functional unit bit string.) If the functional unit groups 
supported by the two application entities do not allow meaningful 
communication, then either entity may refuse the association. 
Meaningful communication is defined as the ability of the entity to 
invoke or perform at least one CMIS operation supported by the other 
entity (i.e., some "complementary" set of functional units exists). 
After an association has been established, a system must provide the 
proper response for functional units that it has indicated it can 
support and should gracefully refuse other requests in accordance 
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with the protocol. 
7.1.4.2. User Information 


The User Information parameter is optional. No entity is required to 
send this parameter, but all entities are expected to tolerate 
receipt of it. 


One possible use of the User Information parameter is to convey 
information describing MIB extensions supported by the manager or 
agent. This can be viewed as a further way of refining the 
application context. The mechanism for doing this is not defined at 
this time. 


7.1.4.3. Access Control 


The CMIS M-INITIALISE Access Control parameter is optional. Access 
control is supported on a per association basis using ACSE. It is 
recommended (but not required) that the access control parameter be 
used for each A-ASSOCIATE request (via M-INITIALISE). 


Access control is also possible on a per request basis with the CMIS 
Access Control parameter. This parameter might be used to implement 
security similar to the community access rights mechanism provided by 
SNMP [4]. It is expected that the Access Control parameter will be 
used to implement the standard TCP/IP authentication mechanism once 
this has been defined. 


7.2. Supporting Services 


The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of 
ACSE. The following ACSE services are required: A-ASSOCIATE, A- 
RELEASE, A-ABORT, and A-P-ABORT. The rest of the CMIP protocol uses 
the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE. 


7.3. CMIP Agreements 


The following sections contain specific CMIP agreements in addition 
to those specified in the CMIP standard [12]. 


7.3.1. Invoke Identifier 


It is required that there be a unique invoke identifier (present in 
the ROSE PDU) for successive invocations on the same association. 

The invoke identifier is provided by the invoking CMISE-service-user. 
Invoke identifiers should increase monotonically during the lifetime 
of an association. Semantically, the invoke identifier is a Counter 
as defined in [2]. Unique identifiers will allow the detection of 
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lost and duplicate requests. 
7.3.2. Object Class 


The object class field of all CMIP PDUs shall be limited to the 
"globalForm" choice: 


ObjectClass 
CHOICE ( 
globalForm [0] IMPLICIT OBJECT IDENTIFIER 


} 


7.3.3. Object Instance 


The object instance field of all CMIP PDUs is limited to the 
"distinguishedName" choice: 


ObjectInstance ::= 
CHOICE { 
distinguishedName [2] IMPLICIT DistinguishedName 
} 


The definition for DistinguishedName is imported from CCITT X.500 and 
ISO DIS 9594-2 [26]: 

DistinguishedName ::= RDNSequence 

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 


RelativeDistinguishedName ::= SET OF AttributeValueAssertion 


The definition for AttributeValueAssertion is contained in CMIP [12]: 


AttributeValueAssertion ::= SEQUENCE { Attributeld, AttributeValue } 
Attributeld ::= 
CHOICE { 
globalld [0] IMPLICIT OBJECT IDENTIFIER 
localId [1] IMPLICIT INTEGER 
) 
AttributeValue ::= ANY DEFINED BY attributeld 


Those attributes to be used as the distinguished attributes of a 
managed object are defined at the time of registration of the object 
class and are identified in the NAMES clause of the OBJECT-CLASS 
macro. 
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When there is no instance information to convey about a managed 
object, then the following "empty" object instance shall be used: The 
"distinguishedName" choice of ObjectInstance shall be an RDNSequence 
consisting of a SEOUENCE of one RelativeDistinguishedName. That 
RelativeDistinguishedName shall be an empty SET of 
AttributeValueAssertions. 


7.3.4. Access Control 


The access control parameter is optional. The receipt of this 
parameter must be tolerated (i.e., gracefully accepted), but a 
receiving entity is free to ignore this information. The Access 
Control field is defined in [12] as EXTERNAL. Until a more 
sophisticated access control mechanism is defined, simple 
authentication can be accomplished by using an unencrypted password 
in the access control field. The definition of this EXTERNAL is the 
same as that for the ACSE Access Control field (section 8.3.2). 


7.3.5. Synchronization 


Support for "best effort" synchronization is required. Atomic 
synchronization may also be supported, but is not required. 


7.3.6. -Scope 


Scoping is supported if the multiple object selection functional unit 
is selected. If scoping is supported, all values of the scope field 
shall be supported. 


TAS Piltēr 


Filtering is supported if the multiple object selection functional 
unit is selected. If filtering is supported, it is not reguired that 
all features of filtering be supported. The following are the 
minimal filtering reguirements for any system that supports 
filtering. In the CMIP field CMISFilter, at least two instances of 
the binary operators ("and," "or") must be supported. Support for 
additional instances of these operators is not reguired. Double 
"not" need not be supported. In FilterItem, the arithmetic 
operations ("eguality", "greaterOrEgual," "lessOrEgual") must be 
supported. The "present" choice of FilterItem must also be 
supported. It is not required to support string operations (namely, 
the "substrings" choice of the FilterItem type). Thus, the minimal 
requirements for filtering yield this restricted definition of 
FilterItem: 
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Filterltem ::= 
CHOICE ( 
equality [0] AttributeValueAssertion, 
greaterOrEgual [2] AttributeValueAssertion, 
lessOrEqual [3] AttributeValueAssertion, 
present [4] AttributeID 


7.3.8. Attribute Identifier 


Both choices for the CMIP Attributeld field are allowed: 


Attributeld ::= 
CHOICE { 
globalld [0] IMPLICIT OBJECT IDENTIFIER, 
localId [1] IMPLICIT INTEGER 


The "globalId" form of Attributeld is required if scoping is used 
(i.e., the value of the scope field is other than "baseObject"). 


7.3.9. Event Type Identifier 


Both choices for the CMIP EventTypeld field are allowed: 


EventTypeld ::= 
CHOICE ( 
globalld [6] IMPLICIT OBJECT IDENTIFIER, 
localld [7] IMPLICIT INTEGER 


7.3.10. Action Type Identifier 


Both choices for the CMIP ActionTypeld field are allowed: 


ActionTypeld = 
CHOICE ( 
globalld [2] IMPLICIT OBJECT IDENTIFIER, 
localld [3] IMPLICIT INTEGER 
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The "globalld" form of ActionTypeld is required if scoping is used 
(i.e., the value of the scope field is other than "baseObject"). 


7.3.11. Time Fields 


The "eventTime" field of the m-EventReport Invoke PDU and the m- 
EventConfirmedReport Invoke PDU must be present. 


The "currentTime" field of the following PDUs must be present: the 
m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set 
Result PDU, the m-Action Confirmed Result PDU, the m-Create Result 
PDU, the m-Delete Result PDU, the GetListError Error PDU, and the 
SetListError Error PDU. 


All CMIP time fields shall use the ASN.1 GeneralizedTime type defined 
in [5] with 1 millisecond granularity. 


If the system generating the PDU does not have the current time, yet 
does have the time since last boot, then GeneralizedTime can be used 
to encode this information. The time since last boot will be added 
to the base time "0001 Jan 1 00:00:00.00" using the Gregorian 
calendar algorithm. (In the Gregorian Calendar, all years have 365 
days except those divisible by 4 and not by 400, which have 366.) The 
use of the year 1 as the base year will prevent any confusion with 
current time. 


If no meaningful time is available, then the year 0 shall be used in 
GeneralizedTime to indicate this fact. 


7.3.12. Response PDUs 


Both the "managedObjectClass" and "managedObjectInstance" fields must 
be present in the following CMIP response PDUs: the m-EventReport 
Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the 
m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete 
Result PDU, the GetListError Error PDU, and the SetListError Error 
PDU. The "managedObjectInstance" field must be present in the 
ProcessingFailure Error PDU. The "managedObjectClass" field must be 
present in the NoSuchArgument Error PDU. 


7.3.13. Error PDUs 


The "globalld" form of Attributeld is required for the 
NoSuchAttributeld Error PDU and the InvalidAttributeValue Error PDU. 


8. Association Control Service Element 


The Association Control Service Element (ACSE), which is necessary 
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for establishing and releasing application associations, is defined 
in [7] and [8]. 


8.1. ACSE Services 


The ACSE service description is detailed in ISO 8649 [7]. All of the 
defined ACSE services are mandatory: 


o A-ASSOCIATE: This confirmed service is used to initiate an 
application association between application entities. 


o A-RELEASE: This confirmed service is used to release an 
application association between application entities without 
loss of information. 


o A-ABORT: This unconfirmed service causes the abnormal release 
of an association with a possible loss of information. 


o A-P-ABORT: This provider-initiated service indicates the 
abnormal release of an application association by the 
underlying presentation service with a possible loss of 
information. 


Mappings of the ACSE services to presentation services and ACSE APDUs 
are shown in Table 6, along with a section reference to ISO 8649 [7]. 


$2 $ AZ O $2 + 
| ACSE | Iso 8649 | Related | Associated | 
| Service | Reference | Presentation Service | APDUs | 
$2 $ AZ O $2 + 
| A-ASSOCIATE | 9.1 | P-CONNECT | AARO, AARE | 
| A-RELEASE | 9.2 | P-RELEASE | RLRO, RLRE | 
A-ABORT 9.3 P-U-ABORT ABRT 
A-P-ABORT 9.4 P-P-ABORT (none) 
+=———————————— do $2 $ + 
Table 6. Mapping of ACSE Services 
8.2. Supporting Services 


ACSE will make use of the following ISO presentation layer services: 
P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT. These presentation 
services will be provided by the LPP [13]. 
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8.3. ACSE Protocol 


The ACSE protocol specification is found in ISO 8650 [8]. A11 five 
ACSE APDUs specified in the standard are mandatory. 


8.3.1. Application Context Name 


The Application Context Name takes the form of an OBJECT IDENTIFIER. 
The value of this OBJECT IDENTIFIER includes both the version of CMOT 
being used for this association and the version number of the highest 
version of the Internet-standard MIB supported by the manager or 
agent. The application context name has the following generic form: 


( iso(1) org(3) dod(6) internet (1) mgmt (2) mib(n) 
cmot (9) cmotVersion(1) version-number (v) ) 


where n = highest MIB version supported and 
v = version of CMOT supported 


For the version of CMOT defined in these agreements, "version-number" 
has the value of one (1). This version of CMOT implies the versions 
of the ISO protocols specified in this memo (see Figure 2). 


8.3.2. User Information 


The following CMIS M-INITIALISE parameters are all mapped onto the 
ACSE User Information parameter: Functional Units, User Information, 
and Access Control. (See section 7.1.4 for more information on the 
CMIS M-INITIALISE parameters.) ACSE User Information is defined in 
ISO 8650 as follows: 


Association-information ::= SEQUENCE OF EXTERNAL 


The ASN.1 defined type EXTERNAL, which is defined in section 35 of 
ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification 
and an associated ASN.1 encoding. 


The OBJECT IDENTIFIER and syntax associated with the ACSE Functional 
Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is 
defined as ( iso(1) standard(0) ips-osi-mips (9596) cmip(2) version(1) 
acse(0) functional-units(0) ) and the syntax is a BIT STRING. 


The EXTERNAL definition for User Information is left unspecified at 
this time; it will be defined in a future memo. 


If some form of access control is required, a simple unencrypted 


Warrier £ Besaw [Page 45] 


RFC 1095 CMOT April 1989 


password can be used. The EXTERNAL for this simple access control 
will use the OBJECT IDENTIFIER ( cmotAcseAccessControl ) (Appendix A) 
and the syntax OCTET STRING. A more sophisticated authentication 
mechanism will be defined with another EXTERNAL definition ina 
future memo. 


8.3.3. Presentation Service Parameters 


The values and defaults of parameters to the ACSE primitives that are 
given to the presentation service are specified in RFC 1085 [13]. 


For the Presentation Context Definition List parameter to the P- 
CONNECT service [13, p. 10], the value of the Abstract Syntax Name 
associated with the Presentation Context Identifier of value one (1) 
shall be identical to the OBJECT IDENTIFIER used for the Application 
Context Name (section 8.3.1). 


The Quality of Service parameter shall have the value of either 
"tcp-based" or "udp-based." 


9. Remote Operations Service Element 


The Remote Operations Service Element (ROSE), which provides the 
ability to invoke remote operations, is specified in ISO 9072-1 [9] 
and 9072-2 [10]. ROSE can only be used once an association has been 
established between two application entities. ROSE is used to 
support CMISE; it is not intended to be used directly by management 
application processes. 


Oale ROSE Services 


The ROSE service definition is detailed in ISO 9072-1 [9]. All of 
the defined ROSE services are mandatory: 


o RO-INVOKE: This unconfirmed service is used by an invoking 
ROSE-user to cause the invocation of an operation to be 
performed by an invoked ROSE-user. 


o RO-RESULT: This unconfirmed service is used by an invoked 
ROSE-user to reply to a previous RO-INVOKE indication in the 
case of a successfully performed operation. 


o RO-ERROR: This unconfirmed service is used by an invoked 
ROSE-user to reply to a previous RO-INVOKE indication in the 


case of an unsuccessfully performed operation. 


o RO-REJECT-U: This unconfirmed service is used by a ROSE-user 
to reject a request (RO-INVOKE indication) of the other 
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ROSE-user if it has detected a problem. It may also be used 
by a ROSE-user to (optionally) reject a reply (RO-RESULT 
indication, RO-ERROR indication) from the other ROSE-user. 


o RO-REJECT-P: This provider-initiated service is used to advise 
a ROSE-user of a problem detected by the ROSE-provider. 


Mappings of ROSE services to ISO presentation services and ROSE APDUs 
are shown in Table 7, along with a section reference to ISO 9072-1 


[9]. 
4+------------- 4+------------ Ho 4+------------- + 
| ROSE | ISO 9072-1 | Related | Associated | 
| Service | Reference | Presentation Service | APDUs | 
4+------------- 4+------------ $ ooo 4+------------- + 
| RO-INVOKE | 10.1 | P-DATA | ROIV | 
| RO-RESULT | 10.2 | P-DATA | RORS | 
| RO-ERROR | 10.3 | P-DATA | ROER | 
| RO-REJECT-U | 10.4 | P-DATA | RORJ | 
| RO-REJECT-P | 10.5 | P-DATA | RORJ | 
4+------------- 4+------------ $ ooo 4+------------- + 


Table 7. Mapping of ROSE Services 


9.2. Supporting Services 


ROSE will only make use of the presentation layer service P-DATA. 
This service is provided by the LPP. The following restrictions are 
a consequence of the use of the LPP: First, mappings to the Reliable 
Transfer Service Element (RTSE) are not possible, since no RTSE is 
present. Second, no data token is used with the presentation 
services. 


9.3. ROSE Protocol 
The protocol specification for ROSE shall follow ISO 9072-2 [10]. 
All four APDUs specified in the standard are mandatory. In addition, 
the ability to support the correct origination and reception of the 
linked-id protocol element is required if the multiple reply 
functional unit has been selected (section 7.1.2). 


9.3.1. Operation Class 


Since no turn management is required by ROSE, the Operation Class 
parameter may be ignored. 
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9. 


10. 


10. 


10 


Fla Priority 

ROSE will deliver each APDU in a "first in, first out" manner. Since 
no turn management is required by ROSE, the Priority parameter may be 
ignored. 


Lightweight Presentation 


The specification for the lightweight presentation protocol (LPP) is 
contained in RFC 1085, "ISO Presentation Services on top of TCP/IP- 


based internets" [13]. The services defined in that memo are the 
minimal set of ISO presentation services required to support ACSE and 
ROSE. The protocol specified to provide these services is a 


replacement for the ISO presentation protocol. 
1. Lightweight Presentation Services 


All of the ISO presentation services provided by the LPP are 
mandatory: P-CONNECT, P-RELEASE, P-U-ABORT, P-P-ABORT, and P-DATA. 


-2. Supporting Services 


Depending on the quality of service indicated in the P-CONNECT 
request, the LPP will use either UDP (low quality) or TCP (high 
quality) as the underlying transport protocol. UDP provides an 
unreliable datagram service, while TCP provides a reliable 
connection-oriented transport service. 


Practically speaking, there are two ways to discover whether a remote 
system supports the LPP over UDP or TCP. The first is to use some 
undefined form of directory service. This might be nothing more than 
a local table. The second way is simply to attempt to establish an 
association with the remote application entity using the desired 
quality of service. If the transport for that service is unavailable 
on the remote system, then the local presentation-service-provided 
will issue a negative P-CONNECT.CONFIRMATION primitive. This will be 
interpreted by ACSE as a failure to establish an association with the 
desired quality of service. 


The following well-known UDP and TCP port numbers are defined: 


cmot manager 163/tcp 
cmot manager 163/udp 
cmot agent 164/tcp 
cmot agent 164/udp 


When UDP is used, an implementation need not accept a lightweight 
presentation PDU whose length exceeds 484. The purpose of this 
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10. 


11. 


12: 


restriction is to ensure that CMIP reguests and responses can be 
transmitted in a single unfragmented IP datagram. 


3. Lightweight Presentation Protocol 


No further agreements are needed for the lightweight presentation 
protocol defined in RFC 1085. 
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Appendix A - The CMOT Group 
CMOT DEFINITIONS ::= BEGIN 
IMPORTS OBJECT-TYPE FROM RFC1065-SMI; 
IMPORTS mib FROM RFC1066-MIB; 


cmot OBJECT IDENTIFIER ::= { mib 9 } 


-- The following assignments are made for the purpose of 
—- identification within CMOT and do not refer to MIB objects. 


cmotVersion OBJECT IDENTIFIER = ( cmot 1 } 
cmotAcseInfo OBJECT IDENTIFIER = ( cmot 2 3 
cmotAcseAccessControl OBJECT IDENTIFIER = ( cmotAcselnfo 1 ) 


-- The following definition is made for use in referencing a 
-- managed system (for the purpose of proxy management) in the 
-- CMIP Object Instance field. It does not represent a MIB 

-- object. 


cmotSystemID OBJECT-TYPE 
SYNTAX CmotSystemID 
ACCESS not-accessible 
STATUS optional 


::= ( cmot 3 } 

CmotSystemID ::= CHOICE ( 
arbitrary [0] IMPLICIT OCTET STRING, 
proxyIndex [1] IMPLICIT INTEGER, 
inetAddr [2] IMPLICIT IpAddress, 
domainName [3] IMPLICIT OCTET STRING, 
mac802Addr [4] IMPLICIT OCTET STRING, 
x121Addr [5] IMPLICIT OCTET STRING, 
nsap [6] IMPLICIT OCTET STRING, 
netbiosName [7] IMPLICIT OCTET STRING, 
snaName [8] IMPLICIT OCTET STRING, 
adminīd [9] IMPLICIT OBJECT IDENTIFIER 


-- All addresses should be conveyed in network-byte order. 


END 
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Appendix B - Management Inf 
RFC1066-MIB-INTERPRETATI 
{ iso org(3) dod ( 
DEFINITIONS 
IMPORTS mgmt, 
mib 
system 


interfaces 
at 


ip 
icmp 
tcp 
udp 
egp 
-- definition of o 
OBJECT-CLASS MACRO 
BEGIN 
TYPE NOTATION 
VALUE NOTATION 
SubClassOf 
Superiors 


Names 
Attributes 
SuperiorList 
Superior 


AttributeList 
Attribute 


END 


-- the System grou 
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CMOT 


ormation Summary 


ON 


6) internet (1) mgmt (2) 


:= BEGIN 


OBJECT-TYPE FROM RFC1065-SMI; 


OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 
OBJECT IDENTIFIER ::= 


bject class 


{ mgmt 1 ) 


SARA AAA a OH 


1 } 


mib 
mib 
mib 
mib 
mib 
mib 
mib 
mib 


AAINNDUAWNE 


RR YM HH — — ww 


April 1989 


::= SubClassOf Superiors Names Attributes 
::= value (VALUE OBJECT IDENTIFIER) 


:= "SUBCLASS OF" value (OBJECT-CLASS) 


::= value (OBJECT-CLASS) 


P 


| empty 

::= "SUPERIORS" "{" SuperiorList 
| empty 

::= "NAMES" "{" Attributelist "}" 
| empty 

::= "CONTAINS" "(" AttributeList 
| empty 

= Superior | Superior "," SuperiorList 


::= Attribute | Attribute "," AttributeList 
::= value (OBJECT-TYPE) 
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system OBJECT-CLASS 


NAMES { cmotSystemID } --— Appendix A 
CONTAINS { 
sysDescr, 
sysObjectID, 
sysUpTime 
} 
::= ( mib; 1 } 


-- the Interfaces group 


interfaces OBJECT-CLASS 
SUPERIORS { system } 
CONTAINS { ifNumber } 
:= [ mib 2 } 


ifTable OBJECT-CLASS 
SUPERIORS { interfaces } 
::= { interfaces 2 } 


ifEntry OBJECT-CLASS 

SUPERIORS { ifTable } 

NAMES { ifIndex } 

CONTAINS { 
ifIndex, 
ifDescr, 
ifType, 
ifMtu, 
ifSpeed, 
ifPhysAddress, 
ifAdminStatus, 
ifOperStatus, 
ifLastChange, 
ifInOctets, 
ifInUcastPkts, 
ifInNUcastPkts, 
ifInDiscards, 
ifInErrors, 
ifInUnknownProtos, 
ifOutOctets, 
ifOutUcastPkts, 
ifOutNUcastPkts, 
ifOutDiscards, 
ifOutErrors, 
ifOutQLen 


::= { ifTable 1 } 
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-- the Address Translation group 


at OBJECT-CLASS 
SUPERIORS { system } 
::= { mib 3 } 


atTable OBJECT-CLASS 
SUPERIORS { at } 
si= { at 1) 


atEntry OBJECT-CLASS 

SUPERIORS ( atTable } 

NAMES { 
atIfIndex, 
atNetAddress 

} 

CONTAINS { 
atIfIndex, 
atPhysAddress, 
atNetAddress 


:= ( atTable 1 } 
-- the IP group 


ip OBJECT-CLASS 

SUPERIORS { system } 

CONTAINS { 
ipForwarding, 
ipDefaultTTL, 
ipInReceives, 
ipInHdrErrors, 
ipInAddrErrors, 
ipForwDatagrams, 
ipInUnknownProtos, 
ipInDiscards, 
ipInDelivers, 
ipOutRequests, 
ipOutDiscards, 
ipOutNoRoutes, 
ipReasmTimeout, 
ipReasmRegds, 
ipReasmOKs, 
ipReasmFails, 
ipFragOKs, 
ipFragFails, 
ipFragCreates 
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::= { mib 4 ) 
——- the IP Interface table 


ipAddrTable OBJECT-CLASS 
SUPERIORS ( ip } 
:= { ip 20 } 


ipAddrEntry OBJECT-CLASS 

SUPERIORS { ipAddrTable } 

NAMES { ipAdEntAddr } 

CONTAINS { 
ipAdEntAddr, 
ipAdEntIfIndex, 
ipAdEntNetMask, 
ipAdEntBcastAddr 


::= ( ipAddrTable 1 } 
-- the IP Routing table 


ipRoutingTable OBJECT-CLASS 
SUPERIORS { ip } 
::= ( ip 21 } 


ipRouteEntry OBJECT-CLASS 

SUPERIORS { ipRoutingTable } 

NAMES { ipRouteDest } 

CONTAINS { 
ipRouteDest, 
ipRoutelfIndex, 
ipRouteMetricl, 
ipRouteMetric2, 
ipRouteMetric3, 
ipRouteMetric4, 
ipRouteNextHop, 
ipRouteType, 
ipRouteProto, 
ipRouteAge 


::= ( ipRoutingTable 1 } 
-- the ICMP group 
icmp OBJECT-CLASS 

SUPERIORS { system } 


CONTAINS { 
icmpInMsgs, 
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icmpInErrors, 
icmpInDestUnreachs, 
icmpInTimeExcds, 
icmpInParmProbs, 
icmpInSrcQuenchs, 
icmpInRedirects, 
icmpInEchos, 
icmpInEchoReps, 
icmpInTimestamps, 
icmpInTimestampReps, 
icmpInAddrMasks, 
icmpInAddrMaskReps, 
icmpOutMsgs, 
icmpOutErrors, 
icmpOutDestUnreachs, 
icmpOutTimeExcds, 
icmpOutParmProbs, 
icmpOutSrcQuenchs, 
icmpOutRedirects, 
icmpOutEchos, 
icmpOutEchoReps, 
icmpOutTimestamps, 
icmpOutTimestampReps, 
icmpOutAddrMasks, 
icmpOutAddrMaskReps 


::= { mib 5 } 
-- the TCP group 


tcp OBJECT-CLASS 

SUPERIORS { system } 

CONTAINS { 
tcpRtoAlgorithm, 
tcpRtoMin, 
tcpRtoMax, 
tcpMaxConn, 
tcpActiveOpens, 
tcpPassiveOpens, 
tcpAttemptFails, 
tcpEstabResets, 
tcpCurrEstab, 
tcpInsSegs, 
tcpOutSegs, 
tcpRetransSegs 


::= { mib 6 } 
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-- the TCP connections table 


tcpConnTable OBJECT-CLASS 
SUPERIORS { tcp } 
= { tep 13-3} 


tcpConnEntry OBJECT-CLASS 

SUPERIORS { tcpConnTable } 

NAMES { 
tcpConnLocalAddress, 
tcpConnLocalPort, 
tcpConnRemAddress, 
tcpConnRemPort 

} 

CONTAINS { 
tcpConnState, 
tcpConnLocalAddress, 
tcpConnLocalPort, 
tcpConnRemAddress, 
tcpConnRemPort 


:= { tcpConnTable 1 } 
-- the UDP group 


udp OBJECT-CLASS 
SUPERIORS { system } 
CONTAINS { 
udpInDatagrams, 
udpNoPorts, 
udpInErrors, 
udpOutDatagrams 


::= { mib 7 ) 


-- the EGP group 


egp OBJECT-CLASS 
SUPERIORS { system } 
CONTAINS { 
egpInMsgs, 
egpInErrors, 
egpOutMsgs, 
egpOutErrors 


::= ( mib 8 3 
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-- the EGP Neighbor table 


egpNeighTable OBJECT-CLASS 
SUPERIORS { egp ) 
::= ( egp 5 } 


egpNeighEntry OBJECT-CLASS 
SUPERIORS { egpNeighTable } 
NAMES { egpNeighAddr } 
CONTAINS { 
egpNeighState, 
egpNeighAddr 


::= { egpNeighTable 1 } 


END 
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Appendix C - Sample Protocol Exchanges 


The following are sample protocol exchanges between a manager and an 
agent. The manager establishes an association with the agent, 
reguests the number of IP address and header errors, reguests the 
type of route corresponding to the destination address 10.0.0.51, 
reguests the TCP connection with the well-known port for FTP, and 
then releases the association. A11 of these samples show the 
lightweight presentation protocol being used over TCP. 


-- the manager sends an ACSE association request carried in a 
-- presentation connect request PDU 


connectRequest ( —— LPP 
version version-l, 
reference ( 
callingSSUserReference "sri-nic.arpa", 
commonReference "8808212225312" 
+, 
asn 1.3.6.1.2.1.9%.1.1, 
user-data ( —— ACSE 
protocol-version versionl, 
application-context-name 1.3.6.1.2.1.9.1.1, 
user-information ( 
functionalUnits ( 
direct-reference 1.0.9596.2.1.0.0, 
encoding ( 
single-ASN1-type ’010110101010101010110B’ 
-- Full Manager 


-- the agent sends an ACSE association response carried in a 
—- presentation connect response PDU 


connectResponse { —— LPP 
user-data ( 


Warrier £ Besaw [Page 60] 


RFC 1095 CMOT April 1989 


user-information ( —— ACSE 
functionalUnits ( 
direct-reference 1.0.9596.2.1.0.0, 
encoding ( 
single-ASN1-type ’101001010101010101110B’ 
-- Full Agent 


-- the manager sends a get request to read the values of 
-- ipInHdrErrors and ipInAddrErrors 


userData { —— LPP 
ro-Invoke { —— ROSE 
invokeID 10, 
operation-value m-Get (3), 
argument ( —— CMIP 
baseManagedObjectClass ( 
globalForm ip ( 1.3.6.1.2.1.4 ) 
+, 
baseManagedObjectInstance { 
distinguishedName ( 
relativeDistinguishedName () 
} 
J, 
attributeldList { 
attributeld ( 
localID 4 —- ipInHdrErrors 
+, 
attributeld ( 
localID 5 —- ipInAddrErrors 


} 
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-- the agent replies with a get response indicating that 
—- ipInHdrErrors = 0 and ipInAddrErrors = 2 


userData { —— LPP 
ro-Result ( —— ROSE 
invokeID 10, 
{ 
operation-value m-Get (3), 
argument { —— CMIP 
baseManagedObjectClass { 
globalForm ip { 1.3.6.1.2.1.4 } 
+, 
baseManagedObjectInstance { 
distinguishedName { 
relativeDistinguishedName {} 
} 
}, 
currentTime "19880821222541.3000002", 
attributeList { 
attribute { 
attributeld { 
localID 4 —- ipInHdrErrors 
}, 
attributeValue 0 
J, 
attribute ( 
attributeld ( 
localID 5 —- ipInAddrErrors 
+, 
attributeValue 2 


-- the manager sends a get request to discover the ipRouteType for 
-- the IP routing entry with ipRouteDest = 10.0.0.51 
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userData { == LPP 
ro-Invoke ( —— ROSE 
invokeID 11, 
operation-value m-Get (3), 
argument ( —— CMIP 
baseManagedObjectClass ( 
globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 } 
}, 
baseManagedObjectInstance { 
distinguishedName { 
relativeDistinguishedName { 
attributeValueAssertion { 
attributeType ipRouteDest 
LA dildos TD. E 
attributeValue 10.0.0.51 


} 
J, 
attributeldList ( 
attributeld ( 
localID 8 —- ipRouteType 


} 


-- the agent replies with a get response indicating the appropriate 
-=- route type 


userData { —— LPP 
ro-Result ( —— ROSE 
invokeID 11, 
{ 
operation-value m-Get (3), 
argument ( —— CMIP 
baseManagedObjectClass ( 
globalForm ipRouteEntry ( 1.3.6.1.2.1.4.21.1 } 
+, 
baseManagedObjectInstance ( 
distinguishedName ( 
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relativeDistinguishedName ( 
attributeValueAssertion ( 
attributeType ipRouteDest 
Lo dd eA 2 dedo kg 
attributeValue 10.0.0.51 


} 
J, 


currentTime "19880821222613.780000Z", 


attributeList ( 

attribute ( 
attributeld ( 
localID 8 


J, 


attributeValue "direct" 


-- the manager sends a get request to read 
-- the well-known port for FTP. 


userData ( 
ro-Invoke ( 
invokeID 12, 
operation-value m-Get (3), 
argument ( 
baseManagedObjectClass ( 


the 


—- ipRouteType 


TCP connection with 


== 1 LPP 
—— ROSE 


= CMIP 


globalForm tcpConnTable ( 1.3.6.1.2.1.6.13 ) 


J, 


baseManagedObjectInstance ( 
distinguishedName ( 


relativeDistinguishedName ( ) 


) 
J, 
scope oneLevel (1), 
filter ( 

item ( 
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equality { 
attributeType tcpConnLocalPort 
(+ de 3 Gabi 2 LO 3 J 
attributeValue 21 ED 


} 


} 
attributeIdList ( } -- an empty list means all attributes 


-- the agent replies with a get response providing the desired TCP 

—- connection information. If more than one TCP connection had 

-—- satisfied the filter condition, a series of one or more linked 

-- reply PDUs would have been returned before the final get response. 


userData { —— LPP 
ro-Result { -- ROSE 
invokeID 12, 
{ 
operation-value m-Get (3), 
argument ( == CMIP 
baseManagedObjectClass ( 
globalForm tcpConnEntry ( 1.3.6.1.2.1.6.13.1 ) 
+, 
baseManagedObjectInstance ( 
distinguishedName ( 
relativeDistinguishedName ( 
attributeValueAssertion { 
attributeType { tcpConnLocalAddress ), 
attributeValue 128.10.0.34 
+, 
attributeValueAssertion { 
attributeType { tcpConnLocalPort }, 
attributeValue 21 
+, 
attributeValueAssertion { 
attributeType { tcpConnRemAddress }, 
attributeValue 0.0.0.0 
+, 
attributeValueAssertion ( 
attributeType { tcpConnRemPort }, 
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attributeValue 0 
J, 


) 
J, 
currentTime "19880821222541.300000Z", 
attributeList ( 
attribute ( 
attributeld ( 
localīd 1 -- tcpConnState 
+, 
attributeValue LISTEN 
+, 
attribute ( 
attributeld ( 
localld 2 -- tcpConnLocalAddress 
J, 
attributeValue 128.10.0.34 
J, 
attribute ( 
attributeld ( 
localld 3 -- tcpConnLocalPort 
J, 
attributeValue 21 
J, 
attribute ( 
attributeld ( 
localīd 4 -- tcpConnRemAddress 
J, 
attributeValue 0.0.0.0 
J, 
attribute ( 
attributeld ( 
localīd 5 —- tcpConnRemPort 
+, 
attributeValue 0 
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-- the manager sends a presentation release request 


releaseRequest { == LPP 
user-data { —— ACSE 
reason normal 


} 


-- the agent sends a presentation release response 


releaseResponse { —— LPP 
user-data { -- ACSE 
reason normal 


} 
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